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(57) Abstract: A system for improving the operation of network based games providing reduced bandwidth requirement and in- 
creased persistency of the game. In one embodiment the invention provides for reduced bandwidth by providing each client computer 
(20) with updates regarding only the inner and border regions associated with the specific client computer. Information regarding 
the balance of the game space is only transferred as required. In another embodiment the system provides for increased persistency 
by allowing playing pieces to be transferred from one player to another player. In a preferred embodiment the playing pieces are 
transferred from a departing player to an artificial agent to maintain the player. In yet another embodiment the invention provides 
for reduced bandwidth by guaranteeing the data path (30) from the server (10) to the client computer (20), while allowing for failed 
communication in the reverse path. 
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MASSIVE MULTIPLAYER REAL-TIME PERSISTENT NETWORK GAME 

ENGINE 

BACKGROUND OF THE INVENTION 
5 The invention relates generally to the field of network game playing, and more 

specifically to an engine for enabling real time game playing over a network. 

With the rapid increase in the number of people worldwide who have access to 
network connected computing devices such as computers, cellular phones and personal 
digital assistants, there is an ever increasing demand for network based gameplay. In 
1 0 particular the rapid growth of the Internet, with it global reach, has spurred the interest in 
networked gameplay. 

Network games are often classified according to the theme or genre of the game. 
Current popular genres include role playing games, educational games, adventure games, 
arcade or action games, simulation games and strategy games, which in a network 
1 5 environment can be played with other players. In some games, most notably strategy 
games, the player controls multiple individual game elements that are moved or 
manipulated in a virtual game world or map. 

Network games are further classified according to the time frames in which 
players interact with one another. In turn-based games each player is typically given a 
20 defined period of time to make decisions and input instructions for the next move. The 
state of the game and all pieces are thus updated in lock step, typically on the order of 
minutes. 

In real-time network games, the state of the game is updated based on moves of 
active players, with no time pre-ordained time constraint. Thus the state of the game is in 
25 constant flux, requiring frequent updating. The bandwidth and processing needs for a 

real-time network game is thus a function of the number of active players and the number 
of game elements. In prior art systems, the location of all game elements, or at least all 
moved game elements are broadcast to all active players on a regular basis. 

In a typical multiple player environment, knowledge of the position of all the 
30 game elements of all the relevant players in a particular area of interest is needed for the 
user to make an informed choice regarding his move. As the number of players increase, 
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and the number of individual game elements controlled by eaeh player increases, the need 
for updating the position of all .be game elements of all .be relevant players demand, 
increased communication bandwidth and processing power. This need is former 
amplified in a real-time network game, in which moves of e.ements by any player may 

occur at any time. 

An additions aspee, of network-based games is the level of pers.stency, and wo 
types of games may be defined, session-based and persistent. In a session-based game, 
the game lasts only as long as all .he players remain connected. The loss of a angle 
piayer thus ends the game. In a persistent game, .he game remains active even when 
some of.be players disconnect In current games of .he persistent type, when a player of 
a nerwork-based game decides to leave the game, the player's game elements are 
typically left unavailable to other players. Furthetmore, .he leaving player is "left 
behind" as .he game continues in the player's absence. Only when .he player reconnects 
can the player's game elements be moved. 

Thus there is a need for a system .hat will allow players leaving a persistent game 
to enable their game elements to be actively involved in .he game even while the player ts 
no. connected. Furthermore diere is a need to minimize the bandwidth involved m 
updating the position of multiple game elements in a nerwork-based game. 

qtlMMARY OF T "F INVENTION 
Accordingly, it is a principal object of the present invention to overcome the 
disadvantages of prior art nerwork game playing. This is provided in the presen. 
invention by a method for nerwork gaming involving a virtual game area divtstble tnro 
regions, and a plurality of networked players each having a. leas, one playing p,ece, 
comprising: determining for each region and for each player whether the region ,s an 
inner region in which the player has a game piece, a border region which is within access 
of a player's piece or an outer region which is no. accessible in this move by the player; 
maintaining a relationship of players and game elements, .he rela.ionship maintaining 
whether said region is an inner region or a border region for each player; and notrfytng 
, only those players for which the region is a border region of changes in the game state. 
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- In a preferred embodiment the invention further provides for notifying only those 
players for which the region is an inner region of all player actions in said inner region. 
In another preferred embodiment the invention further provides for notifying only those 
players for which the region is an inner region or a border region of all player actions in 
5 those regions. In one embodiment the regions are squares, and in another embodiment 
the regions are hexagons. 

In an exemplary embodiment the invention further provides for game persistency 
by: receiving.notification by a server of an impending disconnection of a player; 
searching available computing resources to determine an available substitute playing 

10 agent; choosing the available substitute playing agent; and updating the maintained 
relationship with substitute playing agent. In one further preferred embodiment the 
invention provides for the searching to comprise finding the available substitute agent 
having inner regions in common with the disconnecting player. In another further 
preferred embodiment the invention provides for the searching to comprise finding the 

1 5 available substitute agent having the maximum amount of inner regions in common with 
the disconnecting player. In yet another further preferred embodiment the invention 
provides for the available substitute agent to be an artificial agent. 

The invention also provides for a system for network gaming involving a virtual 
game area divisible into regions comprising: a plurality of networked players, each player 

20 having at least on playing piece; a server, connected to each playing entity by a data 
connection, the server providing: determining functionality for determining for each 
region and for each player whether the region is an inner region in which the player has a 
game piece, a border region which is within access of a players piece or an outer region 
which is not accessible in this move by the player; maintaining functionality associated 

25 with the determining functionality for maintaining in the server a relationship between 
players and game elements, the relationship comprising whether the region is an inner 
region or a border region for each player; and notifying functionality associated with the 
maintaining functionality for notifying only those players for which the region is a border 
region of changes in the game state. 

30 In one preferred embodiment the invention further provides for the notifying 

functionality to notify only those players for which the region is an inner region of player 

3 
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actions in the inner region. In another preferred embodiment the invention further 
provides the notifying functionality to notify only those players for which the region is an 
inner region or a border region of player actions in those regions. In one embodiment the 
regions are squares, and in another embodiment the regions are hexagons. 

In another preferred embodiment the invention further provides: receiving 
functionality for receiving notification by the server of an impending disconnection of a 
player; searching functionality associated with the receiving functionality for an available 
substitute playing agent; bandwidth availability functionality for determining the 
currently available bandwidth to each available substitute playing agent; computing 
resource availability functionality for determining the currently available computing 
resources of each available substitute playing agent; choosing functionality associated 
with the searching functionality the bandwidth availability functionality and the 
computing resource availability functionality for choosing the available substitute playing 
agent having required bandwidth requirements and available computing resources; 
updating functionality associated with the choosing functionality and the maintaining 
functionality for updating the maintaining functionality with the substitute available 
playing agent. 

In one further preferred embodiment the invention provides for the choosing 
functionality to find the available substitute agent having inner regions in common with 
the disconnecting player. In another further preferred embodiment the invention provides 
for the choosing functionality to find the available substitute agent having the maximum 
amount of inner regions in common with the disconnecting player. In one further 
preferred embodiment the available playing agent is an artificial agent. 

The invention also provides for a method for persistent network gaming for a 
plurality of networked players, comprising; receiving notification by a server of an 
impending disconnection of a networked player, the player having at least one gaming 
piece; searching available computing resources to determine an available substitute 
playing agent; choosing the available substitute playing agent; and transferring control of 
the gaming pieces to the available agent. 

In one further preferred embodiment the invention provides for the searching to 
further comprise finding the available substitute agent having minimum bandwidth 
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requirements. In another further preferred embodiment the available substitute agent is 
an artificial agent. In another further preferred embodiment at least some of said 
available computing resources are co-resident with at least one networked player. 
The invention also provides for a system for persistent network gaming 
5 comprising: a plurality of networked players; and a server providing: receiving 

functionality for receiving notification by the server of an impending disconnection of a 
player; searching functionality associated with the receiving functionality for searching 
available computing resources to determine an available substitute playing agent; 
bandwidth determining functionality associated with the searching functionality for 

10 determining the bandwidth requirements and availability for each available substitute 
playing agent; choosing functionality associated with the ranking functionality for 
choosing the available substitute playing agent with minimum bandwidth requirements; 
transferring flinctionality associated with the choosing functionality for transferring at 
least one game piece to the chosen available substitute playing agent. 

15 In one further preferred embodiment the available playing agent is an artificial 

agent. In another further preferred embodiment at least some of the additional computing 
resources are co-resident with at least one networked player. 

The invention also provides for a system for network based gaming comprising: a 
client computer; and a data connection connecting the client computer to a server; the 

20 client computer comprising an application program and a communication module, the 

communication module further comprising: assembling functionality for assembling 

* 

messages from the application program into packets for delivery to the server computer 
over the data connection; message storage functionality associated with the assembling 
functionality for storing a copy of the messages prior to said delivery; received packet 

25 storage number functionality for maintaining a list of received packets from said server; 
disassembler functionality associated with the received packet storage number 
functionality for disassembling the received packets from the server, the disassembler 
functionality further providing: examining functionality associated with the message 
storage functionality for examining the received packet for an acknowledgement or 

30 retransmit request of the stored message by the server; marking functionality associated 
with the message storage functionality and the examination functionality for marking the 

5 
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stored messages with the acknowledgement or retransmit request ; and transfer 
functionality associated with the marking functionality for transferring the marked 
messages from the message storage to the application program. 

In one preferred embodiment the invention further provides for the disassembler 

5 functionality to further provide calculating functionality associated with the storage 
functionality for determining if the received packet is in numerical sequence with 
previously received packets. In another preferred embodiment the invention further 
provides for the disassembler functionality to further provide notifying functionality 
associated with the calculating functionality for generating a retransmit request to the 

1 0 server. 

The invention also provides for a method for network gaming comprising: 
assembling messages from an application program into a packet for delivery to a server 
computer over a data connection; storing a copy of the messages; disassembling a 
received packet from the server computer comprising: storing a serial number of the 

1 5 received packet; examining the received packet for successful acknowledgement or 

retransmit request of at least one stored message; marking the stored messages with the 
result of the examination; and transferring the marked stored messages from the message 
storage to the application program. 

In a preferred embodiment the invention also provides for calculating if said 

20 received packet is in numerical sequence with previously received packets. Still further 
preferably the invention provides for generating a retransmit request in an out of 
sequence event. In another preferred embodiment the invention further provides for the 
application program acting upon the acknowledged messages, and generating new 
messages in response to said unacknowledged messages. 

25 Additional features and advantages of the invention will become apparent from 

the following drawings and description. 

BRIEF DESCRIPTION OF THF. DRAWINGS 
For a better understanding of the invention and to show how the same may be 
30 carried into effect, reference will now be made, purely by way of example, to the 
accompanying drawings. 
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With specific reference now to the drawings in detail, it is stressed that the 
particulars shown are by way of example and for purposes of illustrative discussion of the 
preferred embodiments of the present invention only, and are presented in the cause of 
providing what is believed to be the most useful and readily understood description of the 
5 principles and conceptual aspects of the invention. In this regard, no attempt is made to 
show structural details of the invention in more detail than is necessary for a fundamental 
understanding of the invention, the description taken with the drawings making apparent 
to those skilled in the art how the several forms of the invention may be embodied in 
practice. In the accompanying drawings: 
10 Fig. 1 illustrates a high level block diagram of a system utilizing the teaching of 

the invention; 

Fig. 2 illustrates a high level flow block diagram of a client computer according to 
the teaching of the invention; 

Fig. 3 illustrates a high level flow chart of the operation of the disassembler of 
15 Fig. 2 according to the teaching of the invention; 

Fig. 4 illustrates a high level functional block diagram of a system according to 
the teaching of the invention; 

Fig. 5 illustrates a high level block diagram of a server according to the teaching 
of the invention; 

20 Fig. 6 illustrates a high level flow chart of the operation of the disassembler of 

Fig. 5 according to the teaching of the invention; 

Fig. 7a illustrates a graphical representation of a reverse position structure on a 
first client computer; 

Fig. 7b illustrates a graphical representation of a reverse position structure of a 
25 second client computer; 

Fig. 8 illustrates a graphical representation of the structure of a single region of a 
reverse position structure on the server; 

Fig. 9 illustrates a high level block diagram of network based game comprising 
playing agents; 

30 Fig. 10 illustrates a high level flow chart of the operation of server 10; and 
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Fig . 1 1 illustrates a high level functional block diagram of the operation of server 



io. 



nF.TAn.ED DESC MP22QN OF THE PREFER RED EMBODIMENTS 
The present embodiments provide a system and method enabling massive 
rnultiplayerrealtimenetworkgaming. A preferred embodiment allows for reduced 
bandwidth by maintaining partitioning of the game space into regions. Regions m wh.ch 
a player has active pieces are defined as inner regions, and the player can calculate 
interactions with other players in an inner region. Regions adjacent to an inner reg,on are 
defined as border regions, and the server broadcasts to players moves of all game 
elements in the player's inner and border regions. For each region the server keeps track 
of all game pieces and for which players the region is an inner or border reg,on. 
Information regarding changes in the game state in that region is only transmuted to 
players for which the region is defined as a border inner region. 

Another preferred embodiment allows transfer of control of game elements by a 
player to another playing entity. Preferably the other playing entity is an artificial playmg 
entity operable to maintain the player's game elements in the game. 

Another preferred embodiment allows for reduced bandwidth requirements by 
allowing for an asymmetrical protocol between a client computer and a server, m winch 
delivery of messages from the server to the client computer are guaranteed, but messages 
from the client computer to the server are not 

Before explaining at least one embodiment of the invention in detail, .t ,s to be 
understood that the invention is no. limited in its application to the details of construct 
and .he arrangement of .he component se, form in the following description or tl.uara.ed 
in the drawings. The invention is applicable to other embodiments or of being pracbced 
or carried ou. in various ways. Also, it is .o be understood .ha. me phraseology and 
terminology employed herein is for the purpose of description and should no, be regarded 

as limiting. . 

Fig 1 illustrates a high level block diagram of a system according to a preferred 
embodiment operative in accordance with the present invention. The system comprises • 
server 10, multiple client computers 20 and data connections 30. Server 10 is connected 
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to each of the multiple client computers 20 by data connection 30. In a preferred 
embodiment data connection 30 comprises a UDP/DP connection over a packet based 
network and optionally the packet based network is the Internet. A game control unit 
(not shown) located on server 10 is operative to control a network-based game, whose 
5 players interact via an application (not shown) running on client computers 20. 

Fig. 2 illustrates a high level block diagram of a client computer 20 of Fig. 1 
operative in accordance with a preferred embodiment of the present invention. Client 
computer 20 comprises application 40 and communication module 50. Communication 
module 50 comprises transmit message buffer 60, packet assembler 70, message storage 

10 80, transmit packet buffer 90 ? transmission agent 100, one end of data connection 30, 
receive packet buffer 1 10, packet disassembler 120, received message buffer 130 and 
received message number storage 140. Application 40 is associated with transmit 
message buffer 60 at the input to communication module 50, and the output transmit 
message buffer 60 is associated with an input of packet assembler 70. A first output of 

1 5 packet assembler 70 is associated with the input of message storage 80, and a second 
output of packet assembler 70 is associated with the input of packet transmit buffer 90. 
The output of packet transmit buffer 90 is associated with an input of transmission agent 
1 00, and an output of transmission agent 100 is associated with the input of receive 
packet buffer 1 10. Transmission agent 90 is further associated bi-directionally to one end 

20 of data connection 30. The output of receive packet buffer 1 1 0 is associated with an 
input of packet disassembler 120, and a second input of packet disassembler 120 is 
associated with the output of message storage 80. One output of packet disassembler 120 
is associated with the input of received message buffer 130, and the output of received 
message buffer 130 is associated, across the output of communicant module 50, with an 

25 input of application 40. Packet disassembler 120 is further associated bi-directionally 
with received message number storage 140, and the output of received message number 
storage 140 is associated with an input of packet assembler 70. A further output of 
packet disassembler 120 is associated with an input of packet assembler 70. 

In operation, application 40 generates messages for transmittal to server 10. The 

30 messages may be queries on the state of the game, typically for identification regarding 
game elements and players in a particular area of the game, requests to move one or more 

9 
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game elements controlled by the application, thus changing the game state, or other 
management messages'. Preferably application 40 does not act upon its request to change 
the game state, and instead functions in a manner to be describer further below. 
Messages generated by application 40 are stored in transmit message buffer 60, which in 

5 a preferred embodiment comprises a first in, first out (FIFO) memory. In a preferred 
embodiment the messages are sequentially enumerated for enabling individual 
acknowledgement. Packet assembler 70 operates at regular intervals to collect messages 
from transmit message buffer 60, and to assemble them into packets. In one embodiment, 
packet assembler 70 operates once every 200 milliseconds, and in another embodiment 

1 0 packet assembler 70 operates once every 300 milliseconds. Optionally, packet assembler 
70 further operates to sequentially number the packets being assembled. The packets are 
assembled with a header, which in a preferred embodiment comprises the serial number 
of the first message in the packet, the number of messages in the packet and the number 
of the last packet received from the server, which is collected from received message 

1 5 number storage 140. Optionally, the header further comprises the sequential number of 
the packet. 

In the event message storage 60 has no messages to transmit, an empty message is 
created indicating client computer 20 and application 40 are still actively connected to 
server 10 (not shown) for the purpose of playing the network-based game. A copy of the 

20 messages sent in the packet are stored in message storage 80, and the packet is sent to 
transmit packet buffer 90. Transmission agent 100 operates to transmit any packets 
found in transmit packet buffer 90 over data connection 30 to server 10 (not shown). In a 
preferred embodiment transmission agent 100 operates under the UDP/IP protocol. 

Packets received by transmission agent 100 from server 10 (not shown) over data 

25 connection 30 are transferred to received packet buffer 1 1 0. Packet disassembler 1 20 
operates promptly to retrieve the received packet from received packet buffer 1 10 and 
disassemble the packet into a header and messages destined for application 40. The 
header comprises the sequential number of any acknowledged messages received by 
server 10 (not shown) from client computer 20, or a request to retransmit specific 

30 messages, or multiple messages. The header further comprises a serial number of the 

current packet. The serial number of the current packet received from the server is stored 
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in received message number storage 140. The sequential number of the acknowledged 
message received is compared with the sequential number of the messages stored in 
message storage 80, and the messages with acknowledged sequential number are 
transferred to received message buffer 130, and a flag or header is appended indicating 
5 that they are messages generated by application 40 that have been acknowledged. The 
message is thus removed from message storage 80. In the event that a retransmit request 
is received, the appropriate messages are retrieved from message storage 80, and the 
messages are transferred to received message buffer 130, and a flag or header is appended 
indicating that they are messages generated by application 40 that have not been 
10 acknowledged. Application 40 generates new messages, which may be different than the 
previously stored messages due to changes in the game state, or changes in the users 
intent. 

The serial number of the packet received is inspected to ensure that it is in 
sequence with the previously received packet, as stored in received message number 

15 storage 140. In the event that a packet is missing, packet disassembler 120 notifies 

packet assembler 70 to generate a retransmit request. Packet assembler 70 utilizes the 
last packet number in sequence found in message number storage 140 in the retransmit 
request, thus indicating the last known proper received packet. In the event that no 
packet is missing, the messages are extracted from the packet, and sent to received 

20 message buffer 130. Application 40 polls received message buffer 130 to accept any new 
received messages. 

Fig. 3 illustrates a high level flow chart of the operation of disassembler 120 of 
Fig. 2. In step 1000 ? the disassembler receives a packet from receive packet buffer 110, 
and in step 1010 the serial number of the received packet is identified and stored in 

25 received message number storage 1 40. In step 1 020 the header of the received packet is 
examined to determine if comprises any retransmit requests. In the event that it 
comprises any a retransmit requests, in step 1030 the messages are transferred from 
message storage 80 and in step 1 040 the messages are marked to indicate they have not 
been acknowledged. In step 1050 the marked messages are sent to the application 40 

30 through received message buffer 1 30. 
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In the event that in step 1020 the header of the received packet was determined 
not to comprise a retransmit request, in step 1060 the serial number of the packet is 
checked against previously stored serial numbers in received message number storage 
140, to determine if the packet has been received in sequence. In the event that a packet 
is missing from the sequence, in step 1070 the packet assembler 70 is notified to send a 
retransmit request to the server, otherwise in step 1080 the packet is examined to find 
message acknowledgements. In the event that the received packet comprises an 
acknowledgement, in step 1 090 the stored message with matching sequential number is 
transferred from message storage 80 and in step 1 100 the messages are marked to 
indicate they have been acknowledged. In step 1 1 10 the messages are sent to application 
40 through received message buffer 130. 

It will be noted that messages sent from the server are checked to ensure that they 
have been fully received, and application 40 will receive no further messages until any 
missing messages are received. This ensures that any game state messages sent by the 
server 1 0 are received in the proper order by client computer 20, thus ensuring that the 
game state on client computer 20 is in synchronization with the known game state for the 
client computer on server 10. Messages sent from client computer 20 may be lost or 
unacknowledged, and the program operates to substitute a more updated message for any 
lost packets. Furthermore, client computer 20 does not operate on messages sent by itself 
without acknowledgement by server 1 0, thus further guaranteeing the synchronization. 
While the above has been described with the acknowledgement, retransmit request and 
serial numbers as part of a header of a message, this is not meant to be limiting in any 
way, and is specifically meant to include the acknowledgement, retransmit request and/or 
the serial number being sent as a message included in the packet. 

Fig. 4 illustrates a high-level functional block diagram of a preferred embodiment 
operative in accordance with the present invention. The system comprises client 
computer 20, server 1 0 and data connection 30. Client computer 20 comprises 
application 40, packet assembler 70, message storage 80 and packet disassembler 120, 
and sending/receiving functionality 160. Packet disassembler 120 comprises 
disassembling functionality 170, storing functionality 180, examiner 190, marker 200, 
transferring functionality 210, calculator 220 and notifying functionality 230. Server 10 
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is connected by data connection 30 to client computer 10 at sending/receiving 
functionality 160. Application 40 is associated with packet assembler 70 and 
transferring functionality 220. Packet assembler 70 is associated with message storage 
80, notifying functionality 220 and sending/receiving functionality 160. Message storage 
5 80 is further associated with disassembler 120 and particularly disassembling 
functionality 170. Disassembling functionality 170 is associated with storing 
functionality 180 and sending/receiving functionality 160 5 and storing functionality 180 is 
further associated with examining functionality 190 and calculator 220. Examining 
functionality 190 is further associated with marking functionality 200, and marking 

1 0 functionality 200 is associated with transfer functionality 210. Calculator 220 is further 
associated with notifying functionality 230, and notifying functionality 230 is associated 
with packet assembler 70. 

In operation the system of Fig. 4 operates in a manner similar to that described 
above in relation to Fig. 1, Fig. 2 and Fig. 3. Messages generated by application 40 are 

1 5 assembled into packets in packet assembler 70, stored in message storage 80, and sent by 
sending/receiving functionality 1 60. Server 10 sends packets comprising messages to 
client computer 20 over data connection 30, and the packets are received by 
sending/receiving functionality 160. The packets are transferred to disassembler 120, at 
disassembling functionality 170, which operates to disassemble the packet into messages 

20 and any header. The serial number found in the header is stored by storing functionality 
1 80. The packet is examined by examination functionality 1 90 to determine if a message 
stored in message storage 80 is acknowledged, or if a retransmit request has been 
received for a message stored in message storage 80. Marking functionality 200 operates 
to mark the messages to indicate the results of the examination, and transfer functionality 

25 200 transfers the marked messages to control program 40. Calculating functionality 220 
calculates if the received packet has been received in sequential order, or if a packet is 
missing, and if a packet is missing notifying functionality 220 operates packet assembler 
70 to generate a retransmit request, indicating the last properly received packet. 

Fig. 5 illustrates a high level block diagram of a server 10 of Fig. 1 according to a 

30 preferred embodiment operative in accordance with the present invention. For clarity, 
server 10 will be described as having only a single communication link with a single 
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20 



* compu,er 20, however it is to be understood that server ,0 may ran mu up e hnks 
^lly, and communicate win, mu,«ip.e Oien, compeers 20 over muUtpie da a 

,60. Communication module , 60 comprises transmit message buffer 60, pack , 
assembler 70, pache, storage 260, transmit packer buffer 90, <— » ^ ~ 
end of data connection 30, receive packer buffer ,10, packet dtsassemb.ec ,2 Wed 
me ssage buffer ,30 and received message number storage 270. Game con«r„. und 250 
associated with me inpu, of rransmi, message buffer 60 a, the input to communion 

,60, and transmit message buffer 60 is associated with an inpu, of packet 
assent 70. Packe, assemb,er 60 is associate* wKh an inpu, of message s,orag= SJ and 
wim an inpu, of packer transmit buffer 90. Packe, transmit buffer 90 ,s associated w * 
Itpu, o, emission agen, ,00, and an output of transmission agen, , 00 ,s assocated 
„i,„ me inpu, of receive packe, buffer , ,0. Transmission agen, ,00 is further b- 
Ilia,, associated wi,h one end of data connection 30. The 
buffer , ,0 is associated with me inpu, of packe. disassembier ,20, and an mpu, of packe, 
disassemb,er ,20 is associa,ed with the outpu, of packe, storage 260 One outpu of 
packe, disassembler ,20 is further associaKd with me inpu, of rece.ved messag buff- 
30, and ,he ou,pu, of received message buffer ,30 is associared wrth the .npu, ofgame 
con.ro, uni, 250 across the ou,pu. of communicarion modu,e .60. Packe, d.sass mbl. 
,20 is further bi-direc,iona,ly associated with received message number storage 270, *m 
, he output of received message number arorage 270 is associated with an 
assembler 70. A further outpu. of packet disassemb.er ,20 is further assocated wtth an 

input of packet assembler 70. 

, operation, game contro, uni, 250 generates messages for Cent » 20 
<n „. shown). The messages may be p,aceme„, ofgame e,em=n,s of players, .de„,,fica,,on 
of game e,enten,s and players in a particular area of ,he game, upda,es regardmg 
game state, or other management messages. Messages generated by game contm. 
u„i,250 are stored in message transmit message storage 60, which in a preferred 
enutodimen. comprises a firs, in, ftrsr ou, (FIFO) memory identified w„h a specfic *~ 
, compeer 20. Packe. assembler 70 opera.es a, regu,ar intervals ro col.ee, messages from 
transmi, message buffer 60, and ,0 assemble them into packets. In one embodtment, 
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packet assembler 70 operates every 200 millisecond, and in a second embodiment packtet 
assembler 70 operates every 300 milliseconds. Packet assembler 70 further operates to 
sequentially number the packets being assembled. The packets are assembled with a 
header comprising the sequential number of the packet, the number of messages in the 
5 packet and the number of the last message received from the individual client computer 
20 (not shown), which is being acknowledged, collected from received message number 
storage 270. 

A copy of the packet is stored in packet storage 260, and the packet is sent to 
transmit packet buffer 90. Transmission agent 1 00 operates to transmit any packets 
1 0 found in transmit packet buffer 90 over data connection 30 to client computer 20 (not 
shown). In a preferred embodiment transmission agent 100 operates under the UDP/1P 
protocol. 

Packets received by transmission agent 1 00 from client computer 20 (not shown) 
over data connection 30 are transferred to received packet buffer 110. Packet 

15 disassembler 120 operates to retrieve the received packet from received packet buffer 1 10 
and disassemble the packet into messages destined for game control unit 250 and a 
header. The header comprises the sequential number of the last packet received by the 
client computer 20 (not shown) from server 10, or a request to retransmit any missing 
messages. In a preferred embodiment the header further comprises a sequential number 

20 of the first message in the packet and the total number of messages in the packet. The 

sequential number of the current message received from client computer 20 (not shown), 
and the total number of messages is stored in received message number storage 270. The 
sequential number of the last packet received by the client computer 20 is compared with 
the sequential number of the packets stored in packet storage 260, and the packet is then 

25 erased from packet storage 260. In the event that a retransmit request is received, the 

requested packets are retrieved from packet storage 260, and sent to packet assembler 70 
for retransmittal. A feature of this invention is that messages from the server 10 are 
resent until confirmation of receipt occurs, whereas messages from client computer 20 are 
not retransmitted. Instead messages from client computer 20 when not acknowledge are 

30 regenerated by the application 40, and may thus be different than the original message 
which was not confirmed. 

15 
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The serial number of the received messages are inspected to ensure that it is in 
sequence with the previously received messages, as stored in received message number 
storage 270. In the event that a message is missing, packet disassembler 120 notifies 
packet assembler 70 to generate a retransmit request. Packet assembler 70 utilizes the 
5 last message number in sequence found in message number storage 270, combined with 
the number of message associated with that last message in the retransmit request, thus 
indicated the last known proper received message. In the event that no message is 
missing, the messages are sent to received message buffer 130. Game control unit 250 
polls received message buffer 130 to accept any new received messages. 

10 Only a single game control unit 250 and a single set of associated communication 

modules are shown. It is to be understood that preferably for each client computer a 
separate logical set of communication modules is utilized, so that messages to and from 
each client computer are handled in accordance with the above protocol. 

Fig. 6 illustrates a high level flow chart of the operation of disassembler 120 of 

1 5 Fig. 4. In step 2000, the disassembler receives a packet from receive packet buffer 1 10, 
and in step 2010 the serial number of the messages are identified and stored in received 
message number storage 270. In step 2020 the received packet is examined to determine 
if it comprises a retransmit request. In the event that it comprises a retransmit request, in 
step 2030 the stored packet is transferred from message storage 80 to packet assembler 70 

20 with instructions to retransmit. It is to be understood that multiple packets may be stored 
and retransmitted. In a preferred embodiment when excessive numbers of 
unacknowledged packets are stored in packet storage 260, game control 250 assumes that 
client computer 20 is disconnected. 

In the event that in step 2020 the received packet was determined not to comprise 

25 a retransmit request, or after step 2030, in step 2040 the serial number of the messages 

are checked against previously stored serial numbers in received message number storage 
270, to determine if the packet has been received in sequence. In the event that a 
message is missing from the sequence, in step 2050 packet assembler 70 is notified to 
send a retransmit request to client computer 20, otherwise in step 2060 the packet is 

30 examined to find an acknowledgement. Preferably, the acknowledgment is part of the 
header. In the event that the received packet comprises an acknowledgement, in step 
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2070 the stored packet with matching sequential number is erased from message storage 
80. In the event that in step 2060 no acknowledgement was found, or after step 2070, in 
step 2080 the messages are sent to game control unit 250 through received message 
buffer 130. Game control unit 250 thus receives messages which have been received in 
5 sequence, and will generate any required acknowledgements as further messages to client 
computer 20. 

Fig. 7a and Fig. 7b illustrate a graphical representation of a reverse position 
structure (hereinafter "RevPos") on two different client computers 20 according to a 
preferred embodiment operative in accordance with the present invention. RevPos is a 

1 0 preferred embodiment in accordance with the present invention of a data structure 
comprising maps, elements and player information. In prior art systems each game 
element has associated with it a particular position on a map. The reverse positioning 
structure of the present embodiment allows the client computer 20 to identify for a given 
position the location and identification of all elements of all relevant players. In order to 

1 5 minimize bandwidth requirement the game area is divided into regions, preferably 

squares or hexagons. Each regions is classified as an inner region, border region or an 
outer region. 

Fig. 7a illustrates the RevPos at a particular time for player 1, and Fig. 7b 
illustrates the RevPos at the same time, or game state, for player 2. For clarity the map is 

20 shown as a two dimensional map of equal squares, however it is to be understood that this 
is not meant to be limiting in any way and is intended to include other types of maps, 
including three dimensional maps and hexagonal regions. In Fig. 7a game pieces of 
player 1 are labeled Al, Bl indicating piece A and B respectively of player 1. Similarly 
the game pieces of player 2 which are relevant are labeled herein B2 and B2. Regions 1 

25 to 8 are not within immediate reach of any of player 1 's pieces, which are assumed to 
only interact within the current region or an adjacent region, and thus regions 1 to 8 are 
unmarked. Regions 9, 10, 1 1, 13, 17, 18 and 19 are each within immediate reach of piece 
Al and regions 10, 1 1, 12, 14, 16, 18, 19 and 20 are within immediate reach of piece Bl. 
These regions are not currently occupied by any piece of player 1 , and are thus marked 

30 with a dotted pattern and are considered border regions. Regions 14 and 15 currently 
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contain piece Al and Bl respectively, and are thus considered inner regions, and are 

marked with a hash pattern. 

Application 40 of client computer 1 calculates interactions for all moves within 
inner regions 14 and 15, and the movement or action of all pieces of any other player 
5 within those inner regions is reported to client computer 20 of player 1 by game control 
unit 250 on server 10. Regions 9, 10, 11,12, 13, 16, 17, 18, 19 and 20 are considered 
border regions for player 1 , as they border on regions containing pieces for player 1 . 
Server 10 notifies player 1 of all data regarding changes in the game state in border 
regions, and the result of any interactions with pieces in border regions is received from 

1 0 game control unit 250 on server 10. 

Regions 1 to 8 are not adjacent to any pieces of player 1, and game control unit 
250 does not informat application 40 on client computer 20 of player 1 of actions that 
occur in these regions. This conserves bandwidth, as only relevant information is bemg 

sent to player 1 . ^ 
15 Fig. 7b illustrates the RevPos of player 2, in which pieces of player 2 are labeled 

A2, B2 and C2 indicating piece A, B and C respectively of player 2. Similarly the 
relevant game pieces of player 1 labeled Al and Bl are shown. Regions 1, 5, 9 and 13 
are not within immediate reach of any of player's 2 pieces, which are assumed to only 
interact within the current region or an adjacent region, and are therefore unmarked. 
20 Regions 2, 3, 4, 6, 8, 10, and 12 are each within immediate reach of piece A2, but 
unoccupied by any other piece of player 2, and are thus marked with a dotted pattern 
indicating a border region. Regions 6, 8, 10, 12, 14, and 16 are within immediate reach 
of piece B2 but unoccupied by any other piece of player 2, and are thus marked w,th a 
dotted pattern indicating a border region. Regions 10, 12, 14, 16,18, 19 and 20 are wrthm 
9 5 immediate reach of piece C2 but unoccupied by any other piece of player 2, and are thus 
marked with a dotted pattern indicating a border region. Regions 7, 11 and 15 currently 
contain pieces A2, B2 and C2 respectively, and are thus considered inner regions and are 

marked with a hash pattern. 

Application 40 of client computer 2 calculates interactions for all moves within 
30 inner regions 7, 11 and 15, and the movement or action of all pieces of any other player 
within those inner regions is reported to client computer 2 by game control unit 250 on 
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server 10. Regions 2, 3, 4, 6, 8, 10, 12, 14, 16, 18, 19 and 20 are considered border 
regions for player 2, as they border on regions containing pieces for player 2. Game 
control unit 250 notifies application 40 on computer 20 of player 2 of all data regarding 
changes in the game state in border regions of player 2, thus the result of any interactions 
5 with pieces in these regions is received from game control unit 250 on server 10. 

Regions 1 , 5, 9, 1 3 and 1 7 are not adjacent to any pieces of player 2, and game 
control unit 250 does not inform application program 40 on client computer 20 of player 
2 of actions that occur in these regions. Not providing information about such outer 
regions conserves bandwidth, as only relevant information is being sent to player 2. It is 
1 0 important to note that thus player 2 received information on action of other pieces 

occurring in region 3, and can calculate results of actions in region 7, whereas player 1 
receives no information about either region 3 or 7. This asymmetrical information 
sharing minimizes the required bandwidth. 

In a preferred embodiment, messages regarding movement or action of all pieces 
1 5 within an inner region comprise player requested actions, and do not comprise a step by 
step calculation ofthe game state in those regions. Application 40 of players for which 
this region is an inner region calculate the game state for inner regions utilizing the 
broadcast messages of player requested actions, thus minimizing bandwidth. As 
indicated above, application 40 only acts upon its own messages upon acknowledgement, 
20 thus ensuring that all players are in synchronization with the game state on server 10 
without requiring detailed messaging of game state updates for inner regions. 

Fig. 8 illustrates a high level graphical representation of the structure of a single 
region in the RevPos on server 10, comprising player information 280 and game element 
information 290. Player information 280 comprises a list of all players who are sent 
25 information regarding movements in the region, which is all players to which this region 
is an inner or boundary region. Game element information 290 comprises all game 
elements within the region, with information regarding which player owns the elements. 
Each single regions RevPos is updated continuously on server 10 by game control unit 
250 in response to moves made by each player and sent by each application 40. 
30 Fig. 9 illustrates a high level block diagram of a system for a network-based game 

in which some ofthe active players are artificial playing entities, comprising computers 
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20 each comprising application 40, artificial playing entity 300 and communication 
modules 50, server 10 and data communication 30. First computer 20 comprises 
application 40 being operated by player 1 associated with first communication module 50 
and first artificial playing entity 300, designated entity A associated with second 
5 communication module 50. Second computer 20 comprises application 40 being 

operated by player 2 associated with first communication module 50 and second artificial 
playing entity 300, designated entity B, associated with second communication module 
50. Third computer 20 comprises application 40 being operated by player 3 associated 
with first communication module 50 and artificial playing entity 300, designated entity C 
10 associated with second communication module 50. First, second and third computer 20 
are connected each connected by data communication lines 30 to server 10. In the event 
that player 1 wishes to cease playing, in a first embodiment player 1 passes control of all 
or some of player 1 's playing pieces to player 2. This is accomplished by sending a 
message in the manner described above in relation to Fig. 3 and Fig. 4 to server 1 0 to 
1 5 transfer the appropriate pieces to player 2 by updating the server RevPos as discussed 
above in relation to Fig. 8. 

In a second embodiment, upon first computer 20 disconnecting from the network, 
control of player 1 's pieces are transferred to an artificial playing entity. Artificial 
playing entities are computer modules designed to play the pieces of the game according 
20 to a pre-programmed routine in the absence of a human player and may comprise 

sophisticated rule sets or artificial intelligence or like technologies. The artificial playing 
entity may be associated with the server, or preferably may be available amongst the 
computing resources found on other computers connected to the network. In a preferred 
embodiment server 10 searches for an available artificial playing agent from amongst the 
25 connected computing resources in a manner that will be described further herein. 

The choice of playing agents A, B or C preferably is accomplished by game 
control unit 250. In one embodiment the choice is accomplished so as to minimize 
bandwidth at any one time. Thus if player 1 and player 2 share many inner and border 
regions, information being sent to application 40 of second computer 20 for player 2 may 
30 be utilized by second computer 20 to update entity B, artificial playing agent 260 on 
second computer 20. A further consideration utilized by game control unit 250 is 
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available computing resources on each client computer 20, as certain computers 20 may 
be have insufficient computing resources support one or more artificial playing agents 
260, whereas other computers 20 may have sufficient computing resources to operate one 
or multiple artificial playing agents 260. In a preferred embodiment client computer 20 

5 regularly updates game control unit 250 of available computing resources and available 
bandwidth. In a further preferred embodiment optimization to find the minimum 
bandwidth is not accomplished, but rather the first client computer 20 sharing inner 
regions with the disconnecting player and having sufficient resources is selected. 

Fig. 10 illustrates a high level flow chart of the operation of game control unit 250 

1 0 for the operation of finding an available artificial playing agent. In step 2200, game 
control unit 250 receives a request to continue the player's gameplay with an available 
artificial agent 300, and in step 2210 game control unit 250 searches RevPos information 
as described above in relation to Fig. 8 for a client computer sharing inner regions with 
the requesting player. In a preferred embodiment multiple client computers are ranked 

1 5 and the player closest to the requesting player in number of inner regions is chosen. In 
step 2220 the found client computer is checked to ensure sufficient available computing 
resources and bandwidth. If in step 2220 the first found client computer has sufficient 
resources and bandwidth, in step 2230 the artificial agent 300 is enabled on the chosen 
computer. In step 2240 the player information and game element information RevPos 

20 files are updated as discussed above in relation to Fig. 8. The selected client computer 20 
regularly updates game control unit 250 about available resources, and if resources 
become unavailable, game control unit 250 will again transfer the requesting player to 
another available agent as indicated above. 

Upon the player returning to the game, game control unit 250 transfers all of the 

25 players game elements from the current artificial agent 300 to the player, and disables the 
playing agent. 

Fig. 1 1 illustrates a high level functional diagram of the operation of game control 
unit 250 for finding a close available computing resource and transferring control to an 
artificial agent 300. Game control unit 250 comprises receiver 320, searcher 330, 
30 bandwidth information storage 340, available resource storage 350, approver 360, updater 
370, position maintainer 380, notifier 390, determiner 400 and divider 410. Receiver 320 
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is associated with searcher 330 and searcher 330 is bi-directionally associated with 
chooser 360. Approver 360 is associated with bandwidth information storage 340, 
available resource storage 350, and updater 370. Updater 370 is associated with 
maintainer 380, and maintainer 380 is associated with enabler 390 and determiner 400. 
5 Determiner 400 is associated with divider 410. 

In operation, divider 410 divides the game space into regions, which as indicated 
above are preferably squares or hexagons, and determiner 400 determines for each region 
which players have the region as an inner, border or outer region. Maintainer 380 
maintains the list of regions during game play, and notifier 390 operates to notify players 
1 0 of changes in the game state in their inner and border regions. 

Receiver 320 receives a request from a player to be replaced by an artificial agent 
300, and operates searcher 330 to find available computing resources for artificial agent 
300. Preferably, the available computing resource comprises a player which shares at 
least one inner region with the requesting player. Still further preferably the searcher 
1 5 finds the available computing resource which shares the maximal amount of inner regions 
with the requesting player. Approver 360 checks available bandwidth stored in 
bandwidth information storage 340 and available computing resources stored on available 
resource storage 350 and if the choice has the needed resources the approved choice is 
passed to updater 370. If the choice is does not have the needed resource, searcher 330 is 
20 prompted to make another choice. Updater 370 updates the lists maintained in 

maintainer 360 with the location of the playing agent, so that control of the game pieces 
and subsequent tracking is properly accomplished. 

It is appreciated that certain features of the invention, which are, for clarity, 
described in the context of separate embodiments, may also be provided in combination 
25 in a single embodiment. Conversely, various features of the invention which are, for 

brevity, described in the context of a single embodiment, may also be provided separately 
or in any suitable subcombination. 

Unless otherwise defined, all technical and scientific terms used herein have the 
same meanings as are commonly understood by one of ordinary skill in the art to which 
30 this invention belongs. Although methods similar or equivalent to those described herein 
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can be used in the practice or testing of the present invention, suitable methods are 
described herein. 

All publications, patent applications, patents, and other references mentioned 
herein are incorporated by reference in their entirety. In case of conflict, the patent 
5 specification, including definitions, will prevail. In addition, the materials, methods, and 
examples are illustrative only and not intended to be limiting. 

It will be appreciated by persons skilled in the art that the present invention is not 
limited to what has been particularly shown and described hereinabove. Rather the scope 
of the present invention is defined by the appended claims and includes both 
1 0 combinations and subcombinations of the various features described hereinabove as well 
as variations and modifications thereof which would occur to persons skilled in the art 
upon reading the foregoing description. 
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WHAT IS CLAIMED IS: 

, A method for network gaming involving a virtual game area divisible into 
' regions, and a plurality of networked playets eaeh having a, leas, one playtng 
piece, comprising: 

determining for eaeh region and fo, each player whether said region is an inner 
regio „ in which said player has a game piece, a border region whtch „ w ; *m 
access of a player's piece or an ooter region which is not accessible ,n ,h,s move 
by the player; 

maintaining a relationship of players and game element said relationship 
maintaining whether said region is an inner region or a border regton for each 
player; and 

notifying only those players for which the region is a border region of changes in 
the game state, 

2 The method of claim 1 further comprising notifying only those players for which 
' the region is an inner region of all player actions in said inner regton. 

3 The method of claim 1 further comprising notifying only those players for which 
' ,he region is an inner re gion or a border region of all player actions ,n satd 

regions. 

4. The method of claim 1 wherein said regions are squares. 

5. The method of claim 1 wherein said regions are hexagons. 

6. The method of claim 1 further providing game persistency by: 
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receiving notification by a server of an impending disconnection of a player; 

searching available computing resources to determine an available substitute 
playing agent; 

choosing said available substitute playing agent; and 

updating said maintained relationship said substitute playing agent. 

7. The method of claim 6 wherein said searching further comprises finding said 
available substitute agent having inner regions in common with said 
disconnecting player. 

8. The method of claim 6 wherein said searching further comprises finding said 
available substitute agent having the maximum amount of inner regions in 
common with said disconnecting player 

9. The method of claim 6 wherein said available substitute agent is an artificial 
agent. 

10. A system for network gaming involving a virtual game area divisible into regions 
comprising: 

a plurality of networked players, each player having at least on playing piece; 

a server, connected to each playing entity by a data connection, said server 
providing: 

determining functionality for determining for each region and for each player 
whether said region is an inner region in which said player has a game piece, a 
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border region which is within access of a players piece or an outer region which is 
not accessible in this move by the player; 

maintaining functionality associated with said determining functionality for 
maintaining in said server a relationship between players and game elements, sa ld 
relationship comprising whether said region is an inner region or a border region 
for each player; and 

notifying functionality associated with said maintaining functionality for notifying 
only those players for which the region is a border region of changes in the game 
state. 

1 1 The system of claim 10 wherein said notifying functionality is further for 
notifying only those players for which the region is an inner region of player 
actions in said inner region. 

12 The system of claim 10 wherein said notifying functionality is further for 
notifying only those players for which the region is an inner region or a border 
region of player actions in said regions. 

13. The system of claim 10 wherein said regions are squares. 

14. The system of claim 10 wherein said regions are hexagons. 

15. The system of claim 10 wherein said server further provides: 

receiving functionality for receiving notification by said server of an impending 
disconnection of a player; 

searching functionality associated with said receiving functionality for an 
available substitute playing agent; 
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bandwidth availability functionality for determining the currently available 
bandwidth to each available substitute playing agent; 

computing resource availability functionality for determining the currently 
available computing resources of each available substitute playing agent; 

choosing functionality associated with said searching functionality said bandwidth 
availability functionality and said computing resource availability functionality 
for choosing said available substitute playing agent having required bandwidth 
requirements and available computing resources; and 

updating functionality associated with said choosing functionality and said 
maintaining functionality for updating said maintaining functionality with said 
substitute available playing agent. 

16. The system of claim 15 wherein said choosing functionality is further for finding 
said available substitute agent having inner regions in common with said 
disconnecting player. 

1 7. The system of claim 1 5 wherein said choosing functionality is further for finding 
said available substitute agent having the maximum amount of inner regions in 
common with said disconnecting player. 

18. The system of claim 15 wherein said available playing agent is an artificial agent. 

19. A method for persistent network gaming for a plurality of networked players, 
comprising; 

receiving notification by a server of an impending disconnection of a networked 
player, said player having at least one gaming piece; 



27 



WO 03/053531 



PCT/IL02/01000 



searching available computing resources to determine an available substitute 
playing agent; 

choosing said available substitute playing agent; and 
transferring control of said gaming pieces to said available agent. 

20. The method of claim 19 wherein said searching further comprises finding said 
available substitute agent having minimum bandwidth requirements. 

21 . The method of claim 19 wherein said available substitute agent is an artificial 
agent. 

22. The method of claim 19 wherein said wherein at least some of said available 
computing resources are co-resident with at least one networked player. 

23. A system for persistent network gaming comprising: 
a plurality of networked players; and 

a server, said server providing: 

(i) receiving functionality for receiving notification by said server of an 
impending disconnection of a player; 

(ii) searching functionality associated with said receiving functionality for 
searching available computing resources to determine an available substitute 
playing agent; 
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(iii) bandwidth determining functionality associated with said searching 
functionality for determining the bandwidth requirements and availability for each 
available substitute playing agent; 

(iv) choosing functionality associated with said ranking functionality for 
choosing said available substitute playing agent with minimum bandwidth 
requirements; and 

(v) transferring functionality associated with said choosing functionality for 
transferring said at least one game pieces to said chosen available substitute 
playing agent. 

24. The system of claim 23 wherein said available playing agent is an artificial agent. 

25. The system of claim 23 wherein at least some of said additional computing 
resources are co-resident with at least one networked player. 

26. A system for network based gaming comprising: 
a client computer; and 

a data connection connecting said client computer to a server; 

said client computer comprising an application program and a communication 
module, said communication module further comprising: 

a) assembling functionality for assembling messages from said application 
program into packets for delivery to said server computer over said data 
connection; 

b) message storage functionality associated with said assembling functionality 
for storing a copy of said messages prior to said delivery; 
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c) received packet storage number functionality for maintaining a list of received 
packets from said server; * 

d) disassembler functionality associated with said received packet storage 
number functionality for disassembling said received packets from said server, 
said disassembler functionality further providing: 

i) examining functionality associated with said message storage 
functionality for examining said received packet for an 
acknowledgement or retransmit request of said stored message by 
said server; 

ii) marking functionality associated with said message storage 
functionality and said examination functionality for marking said 
stored messages with said acknowledgement or said retransmit 
request ; and 

iii) transfer functionality associated with said marking functionality for 
transferring said marked messages from said message storage to 
said application program. 

27. The system according to claim 26 wherein said disassembler functionality further 
provides calculating functionality associated with said storage functionality for 
determining if said received packet is in numerical sequence with previously 
received packets. 

28. The system according to claim 26 wherein said disassembler functionality further 
provides notifying functionality associated with said calculating functionality for 
generating a retransmit request to said server. 

29. A method for network gaming comprising: 

assembling messages from an application program into a packet for delivery to a 
server computer over a data connection; 
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storing a copy of said messages; 

disassembling a received packet from said server computer, said disassembling 
comprising: 

i) storing a serial number of said received packet; 

ii) examining said received packet for successful acknowledgement or 
retransmit request of at least one of said stored messages; 

Hi) marking the messages of said stored messages with the result of said 
examination; and 

iv) transferring said stored messages from said message storage to said 
application program. 

30. The method according to claim 29 further comprising calculating if said received 
packet is in numerical sequence with previously received packets. 

31. The method according to claim 30 further comprising generating a retransmit 
request in an out of sequence event. 

32. The method according to claim 29 further comprising said application program 
acting upon said acknowledged messages, and generating new messages in 
response to said unacknowledged messages. 
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